本篇文章將延續昨天的 Collector 元件介紹，探討將 Collector 部署到生產環境時的幾個策略。

根據官方文件，Collector 的部署可分為三種類型，分別是 No Collector、Agent和Gateway，各個類型有其適用場景及優缺點。

No Collector

顧名思義，就是不使用 Collector！OpenTelemetry 可以單純使用 SDK 將 telemetry 送到儲存後端。

在這種模式下，應用程式直接透過 OpenTelemetry SDK 將 traces、metrics 和 logs 發送到觀測性後端，如 Jaeger、Prometheus 或其他雲端服務。

優點：

• 架構簡單：不需要額外維運 Collector

缺點：

• 功能受限：缺乏資料處理能力，無法進行過濾、採樣或轉換。支援的 Exporter 也會因為該語言的 SDK 而有所限制
• 連線複雜：應用程式需要直接處理多個後端的連線
• 管理分散：難以統一管理 telemetry 的配置和路由

因此，No Collector 的部署通常被建議用於開發或測試環境。畢竟當需求變動時，No Collector 相較起來還是比較沒有彈性的。

Agent

Agent 模式是將 Collector 部署在接近應用程式的位置，例如 Kubernetes中的 sidecar（用以觀察 Pod）或者 DaemonSet（用以觀察各個節點）。

優點：

• 低延遲: 資料在本地處理，無需透過網路傳輸
• 故障隔離: 單一節點故障不影響其他節點的 telemetry 收集
• 簡化配置: 每個 agent 只需處理本地應用程式的需求

缺點：

• 資源開銷: 每個節點都需要運行 Collector
• 管理複雜: 需要確保所有 agent 的配置同步，且隨著節點增加，管理成本也跟著上升

Gateway

Gateway 模式採用集中式架構，將 Collector 部署為閘道服務，處理來自多個來源的 telemetry 資料。

優點：

• 集中管理: 統一的採樣、過濾和路由策略，也支援集中管理的加密以及認證(Authentication)
• 資源效率: 共享處理能力，避免重複資源配置
• 後端保護: 防止資料流量過大，直接打進後端

缺點：

• 單點風險: Gateway 故障可能影響整個系統的觀測性，需要考慮設計高可用性或者負載平衡的設計
• 延遲增加: 因為資料都透過網路傳輸，會有相當的延遲性

Agent v.s. Gateway 的差異

由於我在閱讀這兩個部署方式時，對這兩者間的差異有些搞混，所以在此比較一下這兩者的不同。

簡單來說，Agent 在本地處理資料，Gateway 透過網路集中處理資料。

不過，這兩種模式並非互斥，實務上經常混合使用。在官方文件中有個很好的例子：

以 Agent 來說：

• 有些 receiver（如：hostmetricsreceiver、filelogreceiver）必須在每個主機上面獨立運行，若使用 Gateway 模式，則會產生重複的資料
• 某些 Processor 需要存取 telemetry 來源的主機資訊，所以沒辦法部署在遠端機器上面

以 Gateway 來說：

• 實現集中化管理的價值。統一處理資料的取樣或者篩選，並將資料輸出到儲存後端

因此，像這樣 Agent 和 Gateway 混合使用的架構分工通常如下：

• Agent Collector: 收集主機和服務的 telemetry，進行基本處理
• Gateway Collector: 接收來自多個 Agent 的資料，進行進階處理和統一導出

這種架構既滿足了技術需求，也實現了效能和管理的最佳平衡。

動手做：在本地部署 Collector並驗證功能

講完三種部署理論後，讓我們在本地快速啟動一個 Collector，確認它能夠接收並輸出資料吧。

Step 1: 建立otel-config.yaml

receivers:
  otlp:
    protocols:
      grpc:
      http:

exporters:
  debug:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [debug]
    metrics:
      receivers: [otlp]
      exporters: [debug]

這個設定讓我們：

• Receiver: 支援OTLP格式的資料以gRPC與HTTP協議傳輸
• Exporter: 使用 debug exporter 把收到的資料詳細印在 Collector 的 stdout
• Service: 同時處理 traces 和 metrics

Step 2: 部署 OpenTelemetry Collector (Docker)

官方支援使用 Container 或者二進位檔的方式執行，這邊我選用 Container 的方式

docker run --rm -p 4317:4317 -p 4318:4318 \
  -v $(pwd)/otel-config.yaml:/config.yaml \
  otel/opentelemetry-collector:latest \
  --config /config.yaml

觀察 container log，會看到已經成功啟動 gRPC 和 HTTP server

Step 3: 資料驗證

開啟另一個終端機視窗，使用 curl 手動送一筆 OTLP 格式的 metrics 到 http endpoint。

編按：其實，若我們使用 SDK，就不需要手動組合 OTLP 格式的資料了，這我們會在明天的章節進行介紹。

curl -X POST -v http://127.0.0.1:4318/v1/metrics \
  -H "Content-Type: application/json" \
  -d '{
    "resourceMetrics": [{
      "resource": {
        "attributes": [{
          "key": "service.name",
          "value": {"stringValue": "my-service"}
        }]
      },
      "scopeMetrics": [{
        "metrics": [{
          "name": "http_requests_total",
          "unit": "1",
          "sum": {
            "dataPoints": [{
              "startTimeUnixNano": "1634000000000000000",
              "timeUnixNano": "1634000001000000000",
              "asInt": "100"
            }]
          }
        }]
      }]
    }]
  }'

如果成功，你應該會在 Collector Container 中看到 debug 輸出顯示收到的 metrics 資料。

結語

今天探討了 Collector 常用的三種部署模式。明天，我們將介紹 OpenTelemetry 的 API 與 SDK，來了解要如何從應用程式發送 OTLP 資料。

參考資料

ControlTheory - OpenTelemetry Collector Deployment Patterns: A Guide

OpenTelemetry Docs - Agent

OpenTelemetry Docs - Deployment

OpenTelemetry Docs - Gateway

OpenTelemetry Docs - Install the Collector